esaulenka

Да, вы правы. Претензию снимаю. Пока нвидия не снизила цены на видеокарточки на порядок-другой, можно считать 6-байтовый ключ надёжным - для его взлома в течении минут нужно железо ценой в десятки килобаксов. Правда, можно арендовать это железо - на 5 минут это будет недорого. Так проверьте. Берём рандомный ключ, берём кусочек "выхлопа" вашей gamma() и брутфорсим. Про 4 байта я писал, когда (по ошибке) решил, что у вас ключ 4-байтовый. В этом случае с очень высокой долей вероятности (зависит от алгоритма и от расположения звёзд) у вас на выходе брутфорса будет 1-2 ключа. Добавлением буквально одного-двух бит известных данных лишние ключи выкидываются. Для простоты эксперимента можете кусок ключа зафиксировать (с соответствующим уменьшением известного текста). Да ничто не мешает взять ИЗВЕСТНЫЙ алгоритм, которым занимались ИЗВЕСТНЫЕ криптоаналитики. Много занимались, и нарыли уязвимости вроде "если собрать миллион пар plain-cipher, можно уменьшить количество вариантов в 2^5 раз" (т.е., на мой дилетантский взгляд, на практике бесполезные). Нет, вы будете использовать свой велосипед, главное преимущество которого - степень квадратности колёс секретна, и хакеру придётся целый день изучать дизассемблер, чтобы её узнать. Вон, в той же XTEA, что вы используете, алгоритм прописан в википедии. И почему-то никто не предлагает там менять дельту "для увеличения длины ключа". Микро-пример из жизни: достался по наследству проект. Там надо генерировать случайное число. Всё по-настоящему, 32 случайных бита. Только самодельный супер-алгоритм, который это делает, почему-то выдаёт только 256 разных случайных чисел...

Да, можно так: https://godbolt.org/z/E1djrKEdb

Да. И это не такая редкая ситуация, когда кусок плэйн-текста известен. Например, в каждом сообщении передаётся какой-то статус, который злоумышленник знает. Зачем в "типа универсальный" алгоритм закладывать такие грабли, я не понимаю. А, да, у вас LFSR вообще 2 байта (я отвык от 16-битного "uint"). Т.е. для его брутфорса нужны 16..18 бит плэйн-текста и что-то быстрее атмеги. Что там у Jenya, он и сам не знает - то ли вайфай с TCP и JSON-ами, то ли 8-байтовый кан-пакет. В первом случае найти несколько известных байт - задача не особо хитрая...

А какое отношение LFSR в блютусе имеет к вашему LFSR ? А-а-а, ну тогда да, нормальная защита. По факту ваше "шифрование" взламывается тупым брутфорсом, если знать 32 бита исходного сообщения. 4-байтный ключ перебирается за считанные секунды.

/**************************************************************************//** * @file cmsis_gcc.h * @brief CMSIS compiler GCC header file * @version V5.3.0 * @date 28. January 2020 ******************************************************************************/ /* * Copyright (c) 2009-2019 Arm Limited. All rights reserved. #ifndef __UNALIGNED_UINT32_WRITE #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wpacked" #pragma GCC diagnostic ignored "-Wattributes" __PACKED_STRUCT T_UINT32_WRITE { uint32_t v; }; #pragma GCC diagnostic pop #define __UNALIGNED_UINT32_WRITE(addr, val) (void)((((struct T_UINT32_WRITE *)(void *)(addr))->v) = (val)) #endif #ifndef __UNALIGNED_UINT32_READ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wpacked" #pragma GCC diagnostic ignored "-Wattributes" __PACKED_STRUCT T_UINT32_READ { uint32_t v; }; #pragma GCC diagnostic pop #define __UNALIGNED_UINT32_READ(addr) (((const struct T_UINT32_READ *)(const void *)(addr))->v) #endif

Мне кажется, у вас с адресом ошибка. От этого 0x7FFEE000 до 0x8000'0000 - целых 68 килобайт. Попробуйте читать чуть дальше. (я, правда, могу путать. С 2368 я работал лет 8 назад...).

Ну, допустим вы это даже как-то сгенерируете. Выбирать нужный вам вариант компилятор как будет? Вас точно не устраивает простейший вариант? void push(int i) { pushinteger(i); } void push(float f) { pushnumber(f); } Ну или полистайте гитхаб в поисках плюсовых обёрток для Луа. Там оно есть. Это десяток однотипных функций, чтобы поместить аргумент в стек перед вызовом функции в интерпретаторе луа (по отдельной функции для каждого типа аргумента). Можете посмотреть описание (https://www.lua.org/manual/5.3/manual.html раздел 4), там всё просто.

А вы вообще пробовали заглянуть в атоловскую техподдержку? http://fs.atol.ru/SitePages/Центр загрузки.aspx файлик "BP21 program manual". Какая вам библиотека нужна для отправки нескольких текстовых строчек в компорт, я не понимаю.

Особенно непонятно, что говногцц предупреждение в этом месте таки выдаёт: https://godbolt.org/z/oKx4djrcr

Ну всё как обычно, ничего нового. Я спорить заканчиваю - кому-то, надеюсь, помогла информация, которую я привёл ранее, а в этой клоунаде участвовать смысла нет никакого.

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

Потому что инициализация выборочных полей массива описана в стандарте C99 (вот тут), но не описана ни в каком стандарте C++. Каких-то черновиков для включения в стандарт вроде б нет (но я очень невнимательно слежу за деятельностью комитета по стандартизации). В прошлом году (наконец-то!) подобный механизм для структур перетащили из C99 в C++20 (см. пункты 3, 4). Так что iar молодцы, конечно, но при перетаскивании этого кода куда-то ещё будут приключения. Я невнимательно читал тему. Это у вас настройки такие, что-ли? Иначе зачем так делать? Микро-совет. Если пишете на плюсах, пишите просто struct Name { ... }; То же самое по смыслу, но а) букв меньше б) в IDE навигации по коду не вылезает анонимная структура.

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

Это называется полиморфизм. Виртуальная функция Free, которая переопределяется в двух наследниках буфера - один наследник читатель, второй - писатель. Но помимо запутанного кода (три класса вместо одного) будет оверхед виртуальных функций. Кажется, можно этого избежать (гуглить CRTP) но я б такое не делал - серьезное усложнение исходников на ровном месте.

Одинаково, да. Только под разные архитектуры его собирают разные команды, и в какие-то не самые популярные ветки новые "фишки" попадают ооочень нескоро. Впрочем, в версии 7.1, которую использует @Harvester, вся нужная магия уже есть (см. выше ссылку на godbolt, там можно мгновенно сравнить разные компиляторы). Осталось только поменять расширение файла с исходником с ".c" на ".cpp". Ваш IAR, кстати, тоже более-менее должен уметь современный С++ (пример, который я показывал, это C++14).

Потому что вам надо пользоваться компилятором, который знает, что такое compile-time optimization. В свежих C++ всё работает, там люди приложили кучу сил, чтобы множество действий, которые должны быть выполнены в процессе старта программы, выполнялись компилятором, и в программу попадало уже готовое значение. https://godbolt.org/z/MbMGnxxGr

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

Блин, ну вбейте уже в гугл "ILI9341 init" и насладитесь десятком вариаций кода, который скармливает этому дисплею портянки каких-то байтиков (без комментариев, что именно эти байтики значат. очень удобно). Там подобных writedata ещё несколько штук должно быть. Очередная тема ни о чём. "Хочу оптимайзить код мач беттер зен компайлер, но не хочу и не буду ридить мануал". Прям вот классика, уже не первая тема тут такая.

Евгений, предлагаю отделить мух от котлет: схемотехника отдельно, софт - отдельно. Например, задачу "сделать нанопотребляющий вход для подсчёта импульсов" я не осилю (текущее решение с включением-отключением подтяжки, если честно, выглядит костылём), а софт под какой-нибудь STM32L010 (выбрано в терре по принципу "самый дешёвый из L-серии) сделать вполне смогу. Ежели что, мой телеграм совпадает с здешним ником.

Кстати, у этой команды синтаксис memcpy. Т.е. cmd dst, src, size, а не cmd ram, flash, size. Возможно, она даже корректно скопирует флеш в рам :-)

Для упрощения диагностики предлагаю проверять содержимое памяти после каждого шага отладчиком. Ну и лог. анализатор на линиях rx-tx тоже может помочь. На первый взгляд, должно работать. Но я занимался чем-то похожим (свой загрузчик, совместимый по командам с FlashMagic) очень давно... Что странно. Документ обещает "COMPARE_ERROR | (Followed by the offset of first mismatch)", т.е. нолик куда-то потерялся... Ну и про то, что адреса должны быть в десятичной системе, вы же в курсе?

А какое у Вас понимание? В данном случае, const - это метод, который не меняет экземпляр класса (т.е. только читает его переменные), static - метод, который вообще не требует наличия экземпляра (т.е. в принципе не может ничего поменять). Следовательно, static метод по определению const.

Мне кажется, тут третий вариант - команда есть, документации нет. Во всяком случае, гугель говорит, что на AT&V SIM800C значением этой +FSEXT отвечает.

Я б, кстати, тоже с удовольствием послушал знающего человека, как тамошние наркоманские банки памяти по-человечески в IDA разбирать.

http://www.keil.com/support/man/docs/uv4/uv4_db_dbg_serialwin.htm Производитель нам сообщает, что эта функция предназначена исключительно для симулятора - отладки без использования реального железа. Т.е. достаточно бесполезная штука, и к вашему случаю мало относящаяся.