У меня есть 100 пиновые мк, при этом write/read() для списков пинов работают с uint32_t, т.е. 32 пина максимум(для всех остальных функций ограничений нет). Добавлять поддержку uint64_t просто нет смысла, а тебе зачем тестить список из 35-х пинов если собираешься использовать максимум 20-ти ногий мк?
а в 20-ноговом корпусе вполне могут существовать гораздо больше пинов. Вот ща 8-ногий STM8L050 изучаю - одна нога как куча пинов, настроить все правильно, особенно в мультирежимном использовании просто квест какой-то А в RM ещё пишут, что если оставшихся пинов нет снаружи, не переживайте, они есть внутри и учитывайте их тоже....
а в 20-ноговом корпусе вполне могут существовать гораздо больше пинов.
Ремапить пины нужно чтобы по максимуму задействовать всю имеющуюся периферию, для ногодрыжной работы со списками пинов это не нужно, наружу их все равно будет торчать максимум 18.
Любая разработка начинается с чтения документации и изучения доступных средств разработки. Данный материал целиком посвящен средствам разработки, включая детальные инструкции по запуску вашего первого приложения на BlueNRG-LP. Описана работа с отладкой STEVAL-IDB011V1, набором инструментов и пакетом ПО позволяющим разработчику быстро войти в курс дела.
не, там не всегда ремапинг. одновременно живут на одной ноге.
Без разницы, если на одной ноге физически объединены 4 пина, то можно использовать периферию выведенную на любой из них, или можно соединить выход одной периферии со входом другой и т.д., но наружу 4 бита не выведешь и в списке пинов будет по-прежнему какой-то один пин из имеющихся четырех.
Что привлекает в SiC по сравнению с кремнием, и какие особенности делают компоненты SiC часто используемыми, несмотря на более высокую стоимость в сравнении с кремниевыми высоковольтными устройствами? – Объясняет специалист ведущего разработчика силовых приборов из карбида кремния, компании Infineon.
Почему ж не выведешь... с программной стороны выведешь все 4 бита наружу, просто физически они выйдут на одной ноге. Я умудрился вывести 0 и 1 одновременно, нечаянно. На ноге примерно половина питания получилась. Полбита Удивительно, но выжило.
И везде будет разный подход вашего С++ компилятора и разный на выходе ассемблер. Это надо учитывать.
В первом случае может быть выполнена дополнительная оптимизация, в трех оставшихся код должен быть одинаковым. Именно код для write(), добавление volatile просто заставит компилятор перечитывать значение переменной "a" из памяти, а не кешировать в регистре. Изменение этой переменной в прерывании вообще ни на что не влияет.
В первом случае может быть выполнена дополнительная оптимизация, в трех оставшихся код должен быть одинаковым.
Не согласен: 1 код: константное выражение, я бы сделал так, в екселе посчитал или еще как и засунул в три BSRR, если три порта используется. Больше от нее не требуется. 2 код: цикл while говорит компилятору что функция используется многократно, соответственно уже свой асм будет. 3 код: скорее всего похоже на ошибку программиста, модификатор volatile будет отброшен компилятором, так как переменная больше нигде не используется. Скорее всего асм код будет таким же как и в коде 2. 4 код: без модификатора volatile было бы ошибкой и не которые компиляторы вырезали бы переменную (а) из прерывания. Но у меня модификатор volatile, в первую очередь этот модификатор говорит компилятору, что переменная может быть использована в прерывании. Соответственно и асм код другой будет, по чему спросите вы, вы за один так не сможете pins1 = a выполнить, если а = 64 битам. 35 пинов за 1 раз не засунуть в 32 битное число. VladislavS просто не посчитал циферки, и я бы не зацепился.
А здесь загрузка в регистр должна выполняться на каждой итерации, вдруг где-то в прерывании данная переменная перезаписывается. От того действительно ли она перезаписывается будет зависеть значение переменной, на генерацию кода это никак не влияет. Естественно если ничего в прерывании не изменяется, то компилятор это ошибкой программиста не посчитает и volatile не уберет, что мы и наблюдаем, ведь у меня никакого прерывания нет.
VladislavS просто не посчитал циферки, и я бы не зацепился.
Всё я посчитал. Именно поэтому в твоём дурацком цикле сделал оптимизацию и убрал 64-битные вычисления. PinList на >32 пина тоже как три пальца об асфальт делается.
Код:
using TWidth = std::conditional_t<(Size>32), uint64_t, uint32_t>;
И дальше используешь для всех вычислений TWidth. Но я слабо представляю себе ногодрыжный интерфейс на 32+ пина. Можно пример какой-нибудь?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
