Это теперь конечно немного обесценивает мою интерпретацию порта E в двоичном коде.
мы же сдвинули это число на 8 разрядов влево, чтобы работать с битами от 8 по 15
HAL_GPIO_WritePin(..., led_state + 1, ...), led_state не увеличился бы на 1, со сдвигом всё то же самое.
led_state = led_state >> 1 | led_state << 7; Сдвиг выполняется от изначального числа два раза, т.е. 00000001.00000000 и 1.10000000.00000000 и тд.
target_include_directories(test PRIVATE ${YOUR_DIRECTORY})
#include.add_executable(main ${PROJECT_SRC})
file(GLOB PROJECT_SRC
"*.h"
"*.cpp"
)
*.h в список исходников -- идея не очень.
по-моему она возникает как раз не в cmd, а в консоли VS Code.
setlocale(LC_ALL, "") мог бы помочь именно здесь.Как ни странно, именно en_US.utf8 с русским текстом на моей русской винде работает нормально...
utf8 имеет значение, и, поскольку она обозначает кодировку, способную представить весь unicode, она будет работать для любых символов. Проблемы будут у людей использующих кодовые страницы типа сp1251.
Насчёт второго - нет, на выходе после расшифровки нужны именно любые символы любых языков.
en_US.utf8?
setlocale(LC_ALL, "")? Второй здесь: зачем там wchar_t, учитывая, что на выходе будут только символы из набора с64?
значит все таки проблема в валгринде?
valgrind --tool=memcheck --leak-check=yes ./$(NAME)valgrind --tool=memcheck --leak-check=yes ./$(NAME) || echo "valgrind error code: $$?"куда тут вставить округление
Поэтому и прошу помощи
> для полноты картины стоит показывать полный лог выполнения команды make
>> не вижу смысла в этом