xvr

У вас слишком медленный клок, верните #5 в forever

Сама 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 у вас отобразятся процессы для флэшки

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

Зто очень странное значение - код никак не может находится в .bss секции. У вас заполнение идёт по 16 байт, а align стоит 8. Увеличте до 16 (иначе вы можете затереть 8 байтов после .bss, что скорее всего не имеет значения, но кто знает) В остальном всё вроде ок

Я хочу сказать, что там НЕ TVS, а принципиально иные защиты (в том числе тиристорная, которую тут вам уже предлагали). Ещё у TI было нечто такое же - немедленное закорачивание питания при превышении порога (там был MOS ключ)

Это main вашей создаваемой таски Точка входа в таску, это и есть epc при старте таски

https://www.bourns.com/products/circuit-protection

Проверьте его тип - должен быть 64х битный. Запуск первого таска делается как возврат из прерывания. Заполняется фрейм, и из него делается возврат. Нужен там eret или просто ret зависит от реализации (видел оба варианта) Ничего. restorecontext не записывает, а читает оттуда. И читает она то, что вы туда записали в pxPortInitialiseStack. Соотвественно содержимое стека должно соотвествовать обоим.

Для начала надо найти в архитектурах eCos что нибудь похожее на ваш целевой процессор, и попытаться сделать из неё. Писать для eCos HAL с нуля и особенно для Cortex-A крайне непростое занятие 😞

Подозреваю что это не адрес главной процедуры таски 🙂 Неправильно проинициализирован стек, проверьте что и как инициализировалось в pxPortInitialiseStack. Соответствует ли это *( pxTopOfStack + _cEPC ) = (StackType_t) pxCode; и то, куда он восстанавливается (pc) Кстати, только сейчас заметил: А где eret ?

У вас vTaskStartScheduler вернулся, а не должен был. Вместо него дожна быпа запустится первая таска. К вас есть отладчик? (По JTAG например). Можете по шагам пройти запуск?