Да, вот так вот. Если мне нужно, чтобы скрипт допускал сложные выражения в качестве параметра, то я и соответствующим образом скобочки расставляю. Но чаще всего этого не нужно, а то и вообще является признаком ошибки/опечатки.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Пасаны, вы бы с таким рвением упражнялись бы в работе MIPI DSI, в работе радиомодуля STM32W55 и реализации ZigBee, в согласовании работы двух ядер в H747. А то - тьфу, какая фигня - как порты более запупенсто скорфигить. Ну чесслово, этой теме уже лет 15, а вы всё еще мусолите её. Ну несерьезно тратить столько страниц темы на такую хню, которая лишь дело вкуса.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Вот-вот. А потом окажется, что для одного пина активный уровень "1", а для другого- "0".
А вот мои макросы с этим справляются прекрасно. Третий параметр обычно именно за это отвечает.
Цитата:
*((volatile uint8_t *)&GPIOA->MODER+3) |= 3<<2;
Имеете в виду что для входов значение OTYPER безразлично? Это добавляется одним условием. Кстати, вариант с F1 был интереснее в плане выбора в какой из регистров писать. И что-то мне подсказывает, что вы ошиблись в смещениях. Как может быть +3 если поля двухбитные. Тем более что в примере вы хотели PA13, там должно быть +(13*2) и маска (0b11<<(13*2)). Но это, конечно, ерунда: в реальном проекте все посчитает компилятор, а он не ошибается.
Цитата:
А просто листинг посмотреть не судьба?
Это было скорее для HAL'овцев если не сумеют отодрать код настройки пина от всего остального. Получить дизасм может оказаться проще.
Цитата:
Я не собираюсь очередное подобие кала писать. Мне нужно лишь упростить написание и чтение кода.
А что упростилось-то? Как была ручная возня с регистрами и битами, так и осталась. Я понимаю отказаться унифицировать специфичное железо, которое в разных МК не совпадает вот совсем. Но GPIO-то везде выполняют одни и те же задачи примерно одним и тем же способом.
Добавлено after 4 minutes 16 seconds:
Цитата:
Пасаны, вы бы с таким рвением упражнялись бы в работе
Мы тут например USB обсуждали. Присоединяйтесь. Как вы считаете, как лучше абстрагировать переключение буферов точек с двойной буферизацией и надо ли это вообще делать? Как лучше обрабатывать события по обмену пакетом - поллингом или колбэками?
USB теперь уже мало кого интересует, а для меня это уже пройденный этап и далее неинтересен. Некоторое время назад был интересен STM32WB55, но известные события огорчили.
Имеете в виду что для входов значение OTYPER безразлично? Это добавляется одним условием.
Конфигурация порта задаётся 7 регистрами (MODER, OSPEED, PUPDR, OTYPER, AFRL, AFRH, ODR(BSRR). В зависимости режима часть регистров (вообще говоря разная) не используется. Это, мягко говоря, далеко не одно условие. Плюс к этому, можно задать опцию "учесть состояние при включении питания", тогда можно не менять те биты, которые уже и так правильно стоят.
И что-то мне подсказывает, что вы ошиблись в смещениях. Как может быть +3 если поля двухбитные. Тем более что в примере вы хотели PA13, там должно быть +(13*2) и маска (0b11<<(13*2)). Но это, конечно, ерунда: в реальном проекте все посчитает компилятор, а он не ошибается.
Я не ошибся. Я же не зря просил кого-нибудь ещё сделать эту, казалось бы обычную, операцию. Чтобы потом сравнить результат. А на этапе компиляции было вычислено, что менять будем данные только в 3-м байте. Соответственно применен байтовый доступ к регистру. Это дало экономию нескольких байт, так как загрузить короткие данные можно в той же инструкции, а 32-битную константу, извините.
На тактовой процессора 72 МГц при FS подключении на обработку одного пакета больше 3000 тактов. Не успеть принять его за это время надо сильно постараться.
Думаю, пора переходить ко второй избитой проблематике портов - максимальная скорость ногодрыга (по отношению к тактовой частоте) Кто напишет наиболее быстрый способ - получит приз в виде ароматной селедки А кто скажет, будет ли через DMA дрыгать ногами быстрее или нет, тот получит и вторую селедку. А третья селедка разыгрывается за ответ на вопрос - а при исполнении кода из SRAM быстрее или медленне будут дрыгаться ножки?
Отучаемся говорить за всех. Если хотите обсуждать экзотические контроллеры, можете выслать их нам, если будет время и желание разобраться с интересующей лично вас периферией, разберемся.
Цитата:
Плюс к этому, можно задать опцию "учесть состояние при включении питания", тогда можно не менять те биты, которые уже и так правильно стоят.
Нет смысла. Экономия трех тактов на старте не даст ровно никакого выигрыша.
Цитата:
AFRL и AFRH разве не то же самое?
Да, примерно то же самое.
Цитата:
менять будем данные только в 3-м байте. Соответственно применен байтовый доступ к регистру.
И как у вашего алгоритма с читаемостью?
Цитата:
На тактовой процессора 72 МГц при FS подключении на обработку одного пакета больше 3000 тактов. Не успеть принять его за это время надо сильно постараться.
Чем примечательно "не успеть"? Если не успеть, хост просто пошлет пакет еще раз, и скорость обмена будет ограничиваться не скоростью USB, а скоростью вашего алгоритма. Но если говорить о точках с одинарной буферизацией, то на время обработки они блокируются, то есть шлют хоста NAK. В HAL именно это ограничивает скорость: длиннющие прерывания, во время которых обмен запрещен.
Я говорю о новых тенденциях и о прогрессе, и не только за себя, а на основании наблюдения за этими тенденциями. USB, особенно в виде FS, основательно потерял популярность. Нынче если и USB, то Type-C с поддержкой Power Delivery. Ну и STM32WB55 - это вовсе не экзотический микроконтроллер. Та же самая стм-ка с таким же ядром Cortex M0+, только добавлен модуль радио. Навряд ли, кстати, вы разберетесь с ZigBee, коль уже третью страницу спорите, как пины конфигурировать
Замечательно с читаемостью. В том плане, что его вообще не надо читать. IDE сама это делает и даёт варианты.
А сам код вполне читаемый, если владеешь языком. Кусочек из него я приводил в этом сообщении под спойлером. Да и какая разница читаемый он или нет? Ты много раз stdio.h читал? Однако пользуешься и не паришься.
Если бы три. А то в десятки раз на конфигурации всего чипа.
Да пусть хоть миллисекунду конфигурируется. Если это происходит только при включении питания, никто не огорчится. Оптимизировать надо то, что выполняется часто.
Цитата:
Ты много раз stdio.h читал?
А что, ваш код уже стал поставляться вместе с компилятором?
Цитата:
У меня примечательно "успеть". Это значит войти в прерывание, забрать пакет и поставить статус "готов" раньше, чем NACK пройдёт.
Если у вас нет двойной буферизации и достаточно активный обмен, то не успеете. Просто потому что следующий пакет может прийти сразу после предыдущего. Вы можете свести шанс к минимуму уменьшением обработчика или все же воспользоваться двойной буферизацией, когда можно спокойно обрабатывать один буфер пока железо будет писать во второй.
Ну так оно часто и выполняется. Конфигурирование лишь один из методов класса. Конфиг тоже, кстати, достаточно часто происходит - новые проекты регулярно закладываются. А просто работа с gpio это уж точно не самая редкая операция и оптимизация происходит при каждом доступе. Да и каждое включение это не такое и редкое событие. И вообще, зачем делать плохо, если можно делать хорошо?
А что, ваш код уже стал поставляться вместе с компилятором?
Вы спрашивали про "читаемость". Как способ хранения и распространения кода связан с его читаемостью? Не надо его читать при применении вообще. IDE сама подсказывает и автоподставляет, я же показывал скриншоты. Причём, для разных чипов это будет свой контент.
А вот что писать в ваших "шифрограммах" не способна подсказать ни одна IDE. Приходится постоянно читать код библиотеки или держать в голове шифры от всего зоопарка чипов? Да ну, на, сочувствую.
когда можно спокойно обрабатывать один буфер пока железо будет писать во второй.
Либо сделать это быстро, а сэкономленное время потратить на обработку данных. 12 МБит это серьёзный поток для обсуждаемых микроконтроллеров. Не хочется чтобы он в /dev/null уходил.
И вообще, зачем делать плохо, если можно делать хорошо?
Зачем усложнять то, что выполняется единственный раз?
Цитата:
Вы спрашивали про "читаемость". Как способ хранения и распространения кода связан с его читаемостью? Не надо его читать при применении вообще.
Ваш код не входит в стандарт, поэтому будет естественным желание его изучить - какие там баги, насколько оптимально написан и т.п. Так что и вопрос "зачем читать чужой код" не менее глупый, чем ассоциация своего кода с stdio. [qoute]А вот что писать в ваших "шифрограммах" не способна подсказать ни одна IDE.[/quote]По stdio она тоже подсказок не выдает. А если серьезно, то если библиотекой можно пользоваться без костылей вроде IDE, это плюс, а не минус.
Цитата:
риходится постоянно читать код библиотеки или держать в голове шифры от всего зоопарка чипов?
Это у вас методы привязаны к чипу, а у меня - к функции. Если мне надо push-pull, оно и будет GPIO_PP для любого чипа.
Цитата:
Либо сделать это быстро, а сэкономленное время потратить на обработку данных. 12 МБит это серьёзный поток для обсуждаемых микроконтроллеров. Не хочется чтобы он в /dev/null уходил.
Я же приводил вроде ссылку на Хабр, где человек сравнивал HAL с нормальными реализациями. Там же есть осциллограммы как пакеты приходят.
Зачем усложнять то, что выполняется единственный раз?
GPIO это самый используемый узел в контроллере. Его как раз и надо сделать хорошо. Конфигурация при включении питания это лишь одна из функций, которая примерно 10% от всего кода GPIO.
Ваш код не входит в стандарт, поэтому будет естественным желание его изучить - какие там баги, насколько оптимально написан и т.п.
Ну, изучите С++ и будете свободно читать, там всё очень красиво и понятно написано. Вас же не смущает необходимость изучить английский, чтобы RM на чип читать?
А если серьезно, то если библиотекой можно пользоваться без костылей вроде IDE, это плюс, а не минус.
Вот умеете же вы всё с ног на голову вывернуть. С одной библиотекой IDE молчит как рыба об лёд, а с другой даёт красивые подсказки. Какая библиотека удобнее? А без подсказок никто не запрещает писать, только это неудобно в обоих случаях.
Наверно это всего лишь разные вкусы. Одному нравится одно другому нравится другое и каждый считает что его метод самый правильный. Сколько людей столько и мнений.
Да. Всякие USB, SPI, I2C далеко не в каждом проекте используются. А GPIO в каждом. При каждом включении питания выполняется конфигурация.
И вас смущает задержка в пару тактов для операции, которая занимает 10^-11 от всего времени. Вы оптимизируете не там.
Цитата:
Конфигурация при включении питания это лишь одна из функций, которая примерно 10% от всего кода GPIO.
От объема, а не от времени. Ну и 10% это явно завышенное число.
Цитата:
Ну, изучите С++ и будете свободно читать
Изучать новый язык только для того чтобы читать лично ваш код? Как-то недостаточно мотивации. Тем более что с этой задачей мой код справляется ничуть не хуже при лучшей читаемости. Давайте я вам лучше подкину две смежные задачи, из которых с первой я справился, а со второй - нет. Как вы знаете, в USB используется ConfigurationDescriptor, разделенный на секции, каждая из которых содержит размер содержимого. Секции могут быть вложенными. Нужен какой-то инструмент чтобы считал этот размер в компил-тайме и подставлял в соответствующее поле дескриптора. Эту задачу я решил. В описании HID некоторые поля могут быть одно-, двух-, трех- и четырехбайтными. В зависимости от этого будет меняться ведущий байт. Нужен какой-то инструмент, которому передается число и он в зависимости от его размера меняет первый байт и разбивает само число по ячейкам. Например,
Да вот вы чтото зарубились на тему кто круче запутает код. Оба перемудрили. Хотя вам нужно было создать небольшой кодогенератор в интерфейсе которого вы выбираете пины и их режимы а кодогенератор генерирует уже готовый и короткий код. Захотели поменять пины - перегенерировали участок кода и всё. Именно вот этот подход будет самым правильным в этом случае.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 26
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения