Если задача только собрать проект (и тесты, например, запустить), то cmake скрывает необходимость установки фреймворков, так как умеет с github-а подтянуть, остается лишь компилятор поставить.
Только удаленная отладка платная, локально все хорошо (что логично ведь это простой openocd). Единственное, что пока в Platformio напрягает - это несвежесть компилятора, что решается путем скачивания и замены файлов в одной директории.
P.S. Чтобы два раза не вставать: использованный ObKo/stm32-cmake нормально из коробки подгружает библиотеки при их отсутствии? Мне не удалось, пришлось править в одном месте явный вызов MakeAvailable подставить.
Не знаю, я почему-то всегда считал, что 12.5, сейчас заглянул в вики, действительно 12. Не совсем доволен, потому что в прошлом году, когда плотно занимался USB на F103, при поддержке EasyLy удалось из CDC выжать 8.8, но там мы, правда, просто через libusb в конкретную конечную точку чистые данные гнали, без служебных данных, так что, наверно, примерно так и выходит.
У вас 256кБ флешки, можно было там готовый образ ФС разместить, чтобы при подключении к компу показывалось не что-то бракованное «отформатируй меня», а нормальная флешка.
Я так и хотел сначала (собственно, по мотивам Вашей статьи), но в итоге решил сделать на RAM, было интересно именно штатными средствами попробовать поработать (включая форматирование).
Спасибо, я понял. Правда, проверять size==sizeof(CBW) опасно, так как точка может быть с макс. размером пакета в 8/16 байтов, это не запрещено, но, как понял, в этом случае должны прилететь N * MaxPacketSize + M (последний).
Со сбросом тоже вроде понял, надо обнулить все аккумуляторы и состояния.
Спасибо за замечания, с первым полностью согласен, что такая проверка необходима.
По поводу второго замечания сходу не уверен, что правильно понял: то есть нужна проверка того, что если размер меньше макс. размера конечной точки, то он обязательно должен быть последним (дополнить структуру CBW)?
Для всех элементов из иерархии я предложил такой набор параметров: всё, что должно быть в дескрипторе + дочерние элементы (то есть для конфигурации интерфейсы, для интерфейсов — конечные точки + что-то классозависимое). Хотя буквально недавно на радиокоте случилась дискуссия с VladislavS, у него видение ровно наоборот: пользователь задает дескриптор всего устройства, а уже суперконфигуратор из него рождает конфигурации, интерфейсы, точки и прочее. Так, наверно, конкретные типы получатся более простыми (по крайней мере банальные параметры типа номера/класса/протокола отпадут). Но уже слишком много сил потрачено, поздно мне переобуваться.
Я соглашусь разве что с нечитаемостью шаблонной магии, все остальное, как мне кажется, читается даже лучше за счет отсутствия лишних параметров (чего получатся добиться за счет статических элементов). А для конечного потребителя магия скрыта: объяви конечные точки, положи их в интерфейсы, интерфейсы положи в конфигурации, конфигурации в устройство и все заработает.
Ответ для Bobovor: тогда я вас не понял, честно говоря. Пока я на опыте вижу такую зависимость: стремление к суперуниверсальности приводит к усложнению кода, по-другому не получалось. И тогда, как вы и сказали, либо писать понятный одноразовый код под текущий проект (считаю это нормальной практикой, кстати, иметь набор сниппетов и их использовать просто), либо однажды нагородить и потом использовать. Как ни крути, большая часть программистов если не сама пишет НЕодноразовый код, то как минимум его использует (в виде различных библиотек).
следить за тем, чтобы корутины достаточно часто отдавали управление
Вряд ли можно вычислить значение этого «часто». Да, конечно, чем больше переключений, тем меньше вероятность словить проблему, но, как известно, если что-нибудь может пойти не так, оно пойдёт не так. Так что пусть уж лучше это выяснится сразу, чем в тот момент, когда условная ракета должна пристыковаться к МКС.
Считаю абсолютно справедливыми замечания по поводу UB и синхронизации, однако пока это хобби, а код больше «proof of concept», то закрываю глаза. Когда придется писать в продакшн (и если придется, надеюсь, что кто-нибудь возьмет на работу:) ), то надо максимально всем этим озадачиться, причем на уровне теории понимая, что и где может пойти не так.
Считаю, что это потянет на отдельный материал (как и вопрос накладных расходов, например). В первую очередь хотел подогреть интерес к теме, предложив примеры самых простых применений.
Конечно, первый пример в общем-то абсолютно не жизненный, однако хотел начать с самого примитивного варианта применения корутин, а дальше его несколько усложнять.
Я думал об этом, но тогда статья бы получилась про корутины, а вопросы планирования стал бы второстепенным (по объему по крайней мере). Старался в местах, где происходит корутинная магия, ссылаться на лекции МФТИ. Лучше, чем лектор Константин Владимиров, я все равно её не объясню:)
Угу, как минимум все они оказались в private-части.
Или более жизненный, на мой взгляд, пример: когда студенты пишут шаблонный класс, то заставляю определение методов вынести отдельно, поэтому в конце файла появляется
Но мы все-таки в первую очередь про ядро. Для подписи usermode программ необязательно привлекать Microsoft, использовать можно хоть Let's Encrypt, условно говоря (они, правда, code-signing не поддерживают и не собираются, но есть GlobalSign, DigiCert).
Перепроверил на достаточно свежей 2004, все нормально, достаточно включения режима testsigning, то есть если делать как написано, то проблем не возникнет.
Все-таки решил перепроверить и Вы оказались правы, если делать ровно так, как написано в статье, то будет ошибка 577. Разверну сегодня стенд, разберусь (надеюсь) и внесу правки. Скорее всего надо либо все-таки сертификат ставить с включенным режимом testsigning, либо запускать систему в особом режиме с отключенным требованием подписи драйверов. Спасибо!
Не могу назвать себя спецом в cmake, но насколько понял из исходников, сценарий там такой примерно:
Если указаны STM32_CUBE_${FAMILY}_PATH или STM32_CMSIS_${FAMILY}_PATH, то взять оттуда.
Если не указаны, то считать, что кубовские библиотеки лежат по пути /opt/STM32Cube${FAMILY}
В utilities.cmake есть функции stm32_fetch_XXX, подтягивающие CMSIS/HAL с github, но я так и не нашел, где они вызываются и вставил руками.
Вопрос такой в итоге: без установленных заранее CMSIS/HAL у вас всё нормально собралось?
Если задача только собрать проект (и тесты, например, запустить), то cmake скрывает необходимость установки фреймворков, так как умеет с github-а подтянуть, остается лишь компилятор поставить.
Только удаленная отладка платная, локально все хорошо (что логично ведь это простой openocd). Единственное, что пока в Platformio напрягает - это несвежесть компилятора, что решается путем скачивания и замены файлов в одной директории.
P.S. Чтобы два раза не вставать: использованный ObKo/stm32-cmake нормально из коробки подгружает библиотеки при их отсутствии? Мне не удалось, пришлось править в одном месте явный вызов MakeAvailable подставить.
Я так и хотел сначала (собственно, по мотивам Вашей статьи), но в итоге решил сделать на RAM, было интересно именно штатными средствами попробовать поработать (включая форматирование).
Со сбросом тоже вроде понял, надо обнулить все аккумуляторы и состояния.
По поводу второго замечания сходу не уверен, что правильно понял: то есть нужна проверка того, что если размер меньше макс. размера конечной точки, то он обязательно должен быть последним (дополнить структуру CBW)?
Ответ для Bobovor: тогда я вас не понял, честно говоря. Пока я на опыте вижу такую зависимость: стремление к суперуниверсальности приводит к усложнению кода, по-другому не получалось. И тогда, как вы и сказали, либо писать понятный одноразовый код под текущий проект (считаю это нормальной практикой, кстати, иметь набор сниппетов и их использовать просто), либо однажды нагородить и потом использовать. Как ни крути, большая часть программистов если не сама пишет НЕодноразовый код, то как минимум его использует (в виде различных библиотек).
Считаю абсолютно справедливыми замечания по поводу UB и синхронизации, однако пока это хобби, а код больше «proof of concept», то закрываю глаза. Когда придется писать в продакшн (и если придется, надеюсь, что кто-нибудь возьмет на работу:) ), то надо максимально всем этим озадачиться, причем на уровне теории понимая, что и где может пойти не так.
Спасибо за замечания, это важно, внесу исправления.
Задумка была в следующем: не писать сразу ОС, а предложить минимальный пример и последовательно его усложнять.
Или более жизненный, на мой взгляд, пример: когда студенты пишут шаблонный класс, то заставляю определение методов вынести отдельно, поэтому в конце файла появляется