xvr

Сама PCRE2 лежит тут - https://github.com/PCRE2Project/pcre2 Для билда используется CMake (mingw там есть). Кросс компиляция из коробки не поддерживается. Внутри PCRE2 опционально используется JIT (c Keil могут быть проблемы, если захотите его использовать) Возьмите что нибудь попроще 🙂

Тогда макисмальный коэфициент заполнения - 50% Мой алгоритм (только надо убрать промежуточный массив и сразу работать на массиве битов) или алгоритм от jcxz

🤪 char get_rnd_byte(int total_ones) { bool buf[8]; for(int i=0; i<8; ++i) buf[i] = i < total_ones; std::random_shuffle(buf, buf+8); char result = 0; for(int i=0; i<8; ++i) result = (result << 1) | buf[i]; return result; } При рисовании побайтно у вас шум будет полосатым 🙂. И плотность менее 1/8 сделать не получится. Генерите сразу строку (моим алгоритмом вполне можно сгенерить, хоть всю картинку сразу)

Делаете массив на 8 байтов, заполняете в нём подряд нужное количество единиц, хвост заполняете нулями. Затем запукаете на него std::random_shuffle. Затем сворачиваете массив в байт. Можно и сразу в байте сделать, но тогда вам придётся изобрести итератор на бит.

ANSI C это не кодировка файла, а стандарт языка. Коментарии в виде // пришли в С из С++ где то в районе С99.

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

Поздравляю!

У вас дира 'Program Files' порвалась 😞 Должно быть "-IC:\\Program Files\\Progress\\MIPS-SDK\\mips-ide\\mipsel-mti-elf\\include\\mips"

У вас по прежнему присустуют библиотеки в сборке, из за этих ключей: -mclib=newlib -lc Уберите его и подсуньте свои memcmp, memcpy и memset

Ссылки на crt0 и библиотеки в ругани остались? Кстати, не вижу у вас в командной строке ни вашего стартапа, ни линкерного скрипта. Должна быть опция -Wl,-T<link-script> и какой нибудь start.o на первой позиции в списке на линковку

Передайте линкеру -nostartfiles -nodefaultlibs -nolibc -nostdlib -nostdlib++

Из листинга с ошибками видно, что он пытается прилинковать стандартный (НЕ FreeRTOS, а системный) стартап. И библиотеки. Посмотрите на пути в вашем листинге. Опция --nostdlib видимо не стоит. И ld скрипт похоже не тот (возможно тоже стандартный, из newlib)

Вы пытаетесь собрать bare metal проект (FreeRTOS) и слинковать его со стандартным startup'ом и библиотеками. Даже если чудом слинкуется, работате не будет - у FreeRTOS должен быть свой startup

CRC это изначально потоковая побитная функция. И вычисляется она именно на потоке битов. У вас же (равно как и у всех) поток не битов, а слов (по 32 бита). Тут возникает вопрос - как битовый поток наложить на поток слов. С нарезкой групп по 32 бита вопросов не возникает, а вот внутри есть разночтения. Можно биты вдвигать с LSB в MSB, а можно с другой стороны. Оба варианта используются, и это как раз ваш случай - певый код двигает с MSB к LSB, второй в другую сторону. Отличаются они направлением сдвига в цикле вычисления (как для варианта с одним битом, так и с байтом). Полиномы для них очевидно совпадают с точностью до побитового разворота, равно как и результаты, которые они вычисляют - так же побитово развёрнуты. Превратить версию LSB в MSB простым изменение полинома нельзя - нужно изменить направление сдвига внутри цикла вычисления

Насколько я помню, надо выбрать какая SPI флэшка у вас подключена, потом ткуть в неё мышкой (что бы она выбралась). После чего в iMPACT Processes у вас отобразятся процессы для флэшки