Посмотрите как реализованы fatfs и stm USB msc, вызывается и пишется блоками по 512 байт. Вот и пример, а выделять отдельно по 4кб для USB и fat глупо, особенно если в чипе всего 20 килобайт оперативы.
Я привел хоть и синтетический пример, но не такой уж и далекий от реального положения вещей
Для mutex стандартной терминологией является down/up, выбор take/give неоправдан в случае если код публикуется для масс.
Не готов согласиться, down/up не совсем отражает суть действия и сходу понятны куда меньше.
take/give тоже не идеал, но имхо ближе к сути, и для знакомых с freeRTOS намного яснее отражает суть. lock/unlock - тоже было бы норм, но...
Где происходит оборачивание навроде spi_cs_activate()/spi_cs_deactivate() более аккуратно выглядит static inline функция, внутри которой всего 3 действия: захват-действие-отпуск, где действие - это вызов еще одной вложенной static inline.
Напишите понятнее, что имеется ввиду? Все функции для работы с spi: прижатие чип селекта, приём и передача определены в другом модуле, здесь им делать нечего.
На 144 строке было бы аккуратнее с early-exit и continue.
Для индикаторных светодиодов внутри помещения для уменьшения номенклатуры резисторов можно пренебречь небольшим отличием светимости, главное, что бы опознавалось нормально.
Кстати и сам clang нормально собирает под arm bare metal, только нужно ему библиотеки сишные подсунуть во время линковки хоть даже от гцц или же собрать себе из исходников ллвмные.
В ответственных применениях типа авиа, авто и мед техники применяются специфические стандарты и требования к коду, где при хорошем подходе нельзя просто так взять и подсунуть левую либу, но это в идеальном мире...
Всё это, конечно, синтакический сахар. Но почему бы не написать цикл while или поднять это условие в for. Количество вопросов уменьшиться, а если ещё и магическое число скрыть за осмысленным именем макроса или константы, то и читаемость кода повысится. Можно хотя бы i назвать как timeout, вы же не перебираете массив по индексам, а ждёте.
На самом то деле, что мешает держать счётчик в ОЗУ и при событии снижения питания (детектирование любым удобным способом) или просто с более длительным периодом записывать в ПЗУ?
Переменную можно разместить в неинициализируемой области (настраиваем скрипт для линкера) и перезагрузки не страшны.
Нужна лишь ёмкость по питанию чуть больше чем обычно. Можно сказать почти бесплатное решение.
Посмотрите как реализованы fatfs и stm USB msc, вызывается и пишется блоками по 512 байт. Вот и пример, а выделять отдельно по 4кб для USB и fat глупо, особенно если в чипе всего 20 килобайт оперативы.
Я привел хоть и синтетический пример, но не такой уж и далекий от реального положения вещей
Согласен, будет выглядеть аккуратнее.
Не готов согласиться, down/up не совсем отражает суть действия и сходу понятны куда меньше.
take/give тоже не идеал, но имхо ближе к сути, и для знакомых с freeRTOS намного яснее отражает суть. lock/unlock - тоже было бы норм, но...
Напишите понятнее, что имеется ввиду? Все функции для работы с spi: прижатие чип селекта, приём и передача определены в другом модуле, здесь им делать нечего.
Подробнее, про какой кусок кода идёт речь?
Метод без прерываний требует прерываний ?
То есть либо тратим такты на бесполезную обработку в основном цикле, либо такты в бесполезной обработке таймера, даже если энкодер не двигается.
Уж лучше в прерывании от ноги все это делать
Для индикаторных светодиодов внутри помещения для уменьшения номенклатуры резисторов можно пренебречь небольшим отличием светимости, главное, что бы опознавалось нормально.
На странице в википедии куда больше информации и куда лучше все это описано ?
Кстати и сам clang нормально собирает под arm bare metal, только нужно ему библиотеки сишные подсунуть во время линковки хоть даже от гцц или же собрать себе из исходников ллвмные.
И где тут тематика разработки под андроид, программирование микроконтроллеров?
Только ссылки на репы? Ну так не интересно.
Лучше напишите какие сложности были, как с этим боролись, примеры схем, исходников.
Пока это похоже на "я парюсь"
У вас же калибровка идет с участием большого брата(ПК) соответственно нет сложностей писать сразу все изменения за раз, а не по одному параметру?
Даже в таком случае можно подцепиться какой нибудь ide или же с помощью vscodе и cortex debug?
Да ладно, а вы посмотрите в другом месте
https://developer.arm.com/downloads/-/gnu-rm
Я ни на что не намекаю, но может нужно в более надежных источниках софт искать?
В ответственных применениях типа авиа, авто и мед техники применяются специфические стандарты и требования к коду, где при хорошем подходе нельзя просто так взять и подсунуть левую либу, но это в идеальном мире...
Интересно, а почему бы не взять гцц еще старее?
Всё это, конечно, синтакический сахар. Но почему бы не написать цикл while или поднять это условие в for. Количество вопросов уменьшиться, а если ещё и магическое число скрыть за осмысленным именем макроса или константы, то и читаемость кода повысится. Можно хотя бы i назвать как timeout, вы же не перебираете массив по индексам, а ждёте.
На самом то деле, что мешает держать счётчик в ОЗУ и при событии снижения питания (детектирование любым удобным способом) или просто с более длительным периодом записывать в ПЗУ?
Переменную можно разместить в неинициализируемой области (настраиваем скрипт для линкера) и перезагрузки не страшны.
Нужна лишь ёмкость по питанию чуть больше чем обычно. Можно сказать почти бесплатное решение.
Странные у вас задачки для повышения. Это же типичная задача для первого-второго курса какого-нибудь универа.
Про vscode было бы интересно увидеть.
Голубчик, про плюсы это вы зря. Если грамотно использовать, то на много интереснее и удобнее выходит.
Где речь про гос банки? Там про компании с госучастием, про банки не сказано.
Ну и где тут работа буфера в раме, если ядро загружено? Прерывания это понятно, но прерывания жутко медленная штука.
Я бы тоже почитал, где это в cortex m0-3 есть буфер для gpio?