Не думал что такой примитивный вопрос вызовет затруднения.....

листинг:
Как видно - чтение порта одно-единственное.

Более на примитивные вопросы не отвечаю. Учимся думать самостоятельно.

Пример можно чего там наделает си++? Так, чтобы даже на минимальном уровне оптимизации было не более, чем в том листинге, что я привёл?
Пример в студию!

Добавлено after 5 minutes 23 seconds:
На паперти подадут.

Добавлено after 2 minutes 2 seconds:
Не всё равно. Смотрим на тот говнокод, что написал ТС и думаем почему.

PS: Ответ "почему" уж был дан ранее.

так почему Вы здесь пишите:

if(!(GPIOA->IDR & (1 << 5))){ // Кнопка V-
Flag.VOL_minus = true;

}else if((GPIOA->IDR & (1 << 5))){
Flag.VOL_minus = false;
}

Неужели Вы не видите, что это бред? Или в Вашем мк есть третий вариант результата проверки !GPIOA->IDR & (1 << 5) ? Какая религия запрещает написать Flag.VOL_minus = !(GPIOA->IDR & (1 << 5)); (я молчу про #define)

До человека совершенно не доходит, что между двумя чтениями сигнал может измениться. С "1" на "0" например.

Может, наоборот, он именно это учитывает

Если будет переход "1"->"0" то при такой "проверке" событие изменения сост.пина может быть потеряно.

jcxz Если кнопки выведены на разные порты то "поштучного" чтения не избежать.
Таковы условия к примеру для тех же адуринко нано/про-мини.
В принципе не столь уж и проблема. Да и схемотехника/топология более удачного размещения компонентов порой свои условия диктует. Это не есть проблема или "некорректность" в данном случае.

aleksey chilov может пока разбирается с примитивом кнопок - каждая только свою фиксированную функцию выполнаяет (минимальный функционал типа настройки параметров -"влево/вправо" и "+/-").
Посему это всего лишь "простейшие кнопы" с минимальным алгоритмом:

по истечении интервала антидребезга (системные часы)

считал ЛВК
привел данные к единообразию (собрал в байт)
сверил с прошлым значением (буфер прошлого значения)

ЕСЛИ

совпало
идем к функции исполнения (switch/case согласно текущего кода комбинации ЛВК )

не совпало
заносим текущие данные в буфер прошлого значения и выход по фальстарту

А дальше по интересам (для менюшки посолиднее и/или "псевдовиндовс" на символьном двустрочнике придется заметно больше поизвращаться).

... а я бы всё-таки начал с того, что сохранил бы необходимую информацию в обработчике прерывания и сбежал бы из него от греха подальше. Впрочем, у меня с армами небогатый опыт, может, там прощается многое.

Не, не, не. Так не честно ) Тут всего 3 пина, но при использовании приходится дублировать чтение IDR из десятка портов и это даже не весь код, а только собственно чтение из порта в переменные ) На C++ будет 2 строки:

Читаем значения наших трех пинов, инвертируем, атомарно записываем обратно не трогая оставшиеся пины. Выхлоп:

Вы сами просили для 3-х.


А где код? Верить на слово?
Очевидно что фраза про "2 строки" - ложь.


код этот ваш делает следующую операцию:
Какое отношение это имеет к теме опроса ног - вообще непонятно....
Также очевидно, что ноги подключенные к кнопкам, настроены на ввод. Какой смысл в них что-то писать? Что это даст?

Выложили какую-то галиматью......
Мой код имеет точно тот же результат (просто чтение GPIO->IDR), но всего в одну команду. Вместо 5-и у вас.

Gl.Registr = GPIOA->IDR;
switch(Gl.Registr){
case 0xFF76:
Flag.SET_Ok = true;
break;
case 0xFFB6:
Flag.VOL_plus = true;
break;
case 0xFFD6:
Flag.VOL_minus = true;
break;
case 0xFFF6:
Flag.SET_Ok = false;
Flag.VOL_plus = false;
Flag.VOL_minus = false;
break;
}

Добавлено after 55 seconds:
Сделал вот так.
Может быть опять запинаете но в отладчике работает

Ну как минимум нужно наложить маску на IDR иначе может быть беда.

Работа с флагами - заведомо тупиковая.
Это хорошо для одиночных управляющих кнопок. Для группы кнопок при перспективе обработки комбинации нескольких одновременно нажатых (актуально для небольшого количества кнопок "джойстикового" типа и "оконного меню") такой подход только усложнит программу.

(как нибудь в котуинке положу тестовый "псевдовиндовс" на референсе Си для адуринок под АВР и жирненький "двустрочник").

aleksey chilov, уже получше. Но запинаю - в таком виде это всё равно бессмысленно. Зачем лишние флаги, если GPIOA->IDR уже куда-то сохранён? И потом, если флаги Flag.SET_Ok и прочие разместить в том же порядке, в котором биты порта, то весь этот case опять заменяется на
Flags.All = GPIOA->IDR; притом, так отловится и одновременное нажатие.
Вы же в курсе по указатели, структуры, объединения, битовые поля?

...и всё ещё без #define...

Имеется в виду, что даже для всего лишь трех пинов придется написать 30 строк только для чтения IDR в переменные.


Очевидно, что я посчитал число строк исключая "f() {}", то есть только строки где идет работа с пинами. Код не мой, писал товарищ, могу спросить можно ли его выложить, надо? Впрочем, я его понимаю на 90%, большинство остальных поймут на 10% ) Ваша недооценка возможностей C++ пропорциональна его незнанию, еще и помноженная на скептицизм, в таком случае за подобной сложности код можно даже и не браться.


Это же пример, скучно просто читать с порта ) Естественно пины были сконфигурированы на вывод.
В данном случае у нас 3 подряд идущих пина, а может быть 30, с разных портов, в любом порядке, и этот мой код продолжит работать без никаких модификаций. То что результат выглядит как простое чтение из порта с накладыванием маски и записью обратно лишь подтверждает оптимизирующую природу используемого алгоритма, либа научена искать подобные маски которыми можно выделить побольше бит и сдвинуть их за раз в нужные позиции. Даже эти три пина после чтения оказываются в трех младших битах результата, просто write() все сдвинула обратно и оптимизатор сдвиги вообще убрал )

Это серьезно? И через напр. 5 дней будете смотреть на код и удивляться, кто ее написал ... и что он хотел сделать ...

Добрый день!
Хочу продолжить тему кнопочек.
Я подумал, и что-то придумал.
Наверное опять будете меня закидывать помидорами и оскорблять но всё же,
посмотрите что я сделал и скажите что-то. Ведь если ругают значит есть повод подумать и
устранить ошибки.

void EXTI9_5_IRQHandler(void){
EXTI->PR = (EXTI_PR_PR5|EXTI_PR_PR6|EXTI_PR_PR7); // Сбросить флаг прерывания!
asm("nop"); // Пропуск для установки флага
asm("nop"); // Пропуск для установки флага
Flag.Butoon = true; // Нажата одна из кнопок
}

Вот тут в этом хендлере флагу "Flag.Butoon" присваивается true.
Этот флаг будет использоваться в функции которая будет обрабатывать кнопки.
Если флаг будет false то когда в обработчике дойдёт очередь до этой функции,
в неё зайдёт и сразу выедет тем самым сократится количество манипуляций.
Если true тогда обработает и присвоит код кнопки переменной которая была нажата 1,2,3
и в конце сбросит флаг "Flag.Butoon".

Дальше...

void Key_handler(bool *Survey, uint8_t *key_kod){
if(!*Survey)return;

if(*Survey){
if(!(GPIOA->IDR & (1 << 7))){
*key_kod = 1;
}

if(!(GPIOA->IDR & (1 << 6))){
*key_kod = 2;
}

if(!(GPIOA->IDR & (1 << 5))){
*key_kod = 3;
}
*Survey = false; // Сбросить после обработки
}
}
Собственно сама функция, тут в ней обработка кнопок.
Через указатели дотягиваемся до флага и переменной и изменяем их если нужно.

Дальше...

void TIM3_IRQHandler(void){
if(READ_BIT(TIM3->SR,TIM_SR_UIF) == 1)
CLEAR_BIT(TIM3->SR,TIM_SR_UIF);
Key_handler(&Flag.Butoon, &Gl.Key_stat);
Calculation_ADC(&Gl.ADC_res_Battrey, 0);
}

Этот хендлер для таймера. Таймер настроен на 100Гц.
Собственно там вызываются 2 функции.
Первая это для кнопок а вторая вычисляет и усредняет данные
от ADC через DMA для стабильной работы.

Всё. Пока что вот так сделал.
Теперь критика ваша, жду...

Посмотрите, это форум. Ни у кого нет цели оскорблять. Только направление на размышление даем.
Напр. смотрю на собственный код из прошлом и задаюсь вопросом: так ли я ето написал? Если рядом был человек, то он мог бы дать направление, и путь будет "короче". Если нет человека, то в интернете, или со своим опытом. Но второй способ происходит значительно медленнее. Так что как решите, так и делайте. Цель одна - сокращенный, чистый код, который впоследствии пригодится вам в других проектах. МК не интересует способ составления алгоритма. Для небольших проектов будет ОК. А вот в больших проектах (и ​​при максимальном использовании ресурсов) будет от: медленного режима до невозможности работы. А когда меняешь начина построяния в коде на другой принцип, алгоритм, вдруг все ОК. (частично использую переводчика)
---

прочитали статус порта 3 раза. Если статус изменился во время чтения? (спомните проблем bounce для кнопки).
Как вариант: прочитайте порт раз, присвойте значение переменной, затем отфильтруйте ее значение по кнопок.

В текущей реализации ТС из-за дребезга можно прочитать одни единички и пропустить нажатие вообще, даже с одной кнопкой. В нормальном случае, со счетчиком для отдельной кнопки или для всех сразу, без разницы сколько раз читать с портов, три чтения GPIOA->IDR ничем не отличаются от чтения GPIOA->IDR + GPIOB->IDR + GPIOC->IDR, если кнопки будут на разных портах.

Да, есть варианты. Но то, что можно читать вместе, лучше/и легче/ читать вместе (например состояние 3 пинов в одном порту).

неужели не видно, что опять можно просто присвоить key_kod`у состояние трёх битов GPIOA->IDR (с маской) за один раз? Более того, они ведь даже подряд идут, если очень хочется, можно даже сделать сдвиг всех трёх и получить 1, 2, 3, если это жизненно важно.
Зачем делать три условия?
печально всё это...