makc

И на неё есть ссылка в примере https://wiki.mik32.ru/SPIFI Но вот на сколько она отечественная вопрос открытый. Скорее всего это корпусированный в России тайваньский чип, как это было с NAND от GS, ЕМНИП.

Вот на это действительно стоит обратить внимание и проверить осциллографом.

При некачественной пайке я такое наблюдал несколько раз, что около 5% плат и даже больше по-разному чудят, в том числе и не запускаются. Может быть это банальный недогрев, посмотрите под микроскопом на форму шаров и сравните их с шарами на рабочих платах. Ещё можно попробовать перед запуском нажать пальцем на корпус посильнее и не отпуская пальца подать питание: если будет запускаться, то это однозначно проблема пайки. Здесь нет ни слова, что несоблюдение приведет к проблемам запуска, это всего лишь способ не перегружать источник в момент пуска. Я пока ни разу не сталкивался с проблемой запуска хилых ПЛИС при одновременной подаче VMGTAVCC и VMGTAVTT, а суммарный тираж плат больше 20e3. Непохоже это на причину проблемы.

Проверьте соответствие порядка подачи питания требованиям документации. Желательно не просто по схеме и описаниям проверить, но и убедиться с помощью осциллографа на дурящих платах, что с этим всё в порядке.

При том, что АЦП будет регистрировать суперпозицию шумов и нужно гарантировать, что правильный шум (имеющий равномерное или подобное ему распределение) будет доминировать. В противном случае получится регистратор наводок от какого-нибудь ШИМ DC/DC. Случайность и независимость этого шума от процессов в системе вы можете обосновать? Я - нет. Посмотрите, как люди бьются с генерацией случайных чисел на кольцевых генераторах... Казалось бы всё просто, но это совсем не так как кажется. 😞 Это не добавляет энтропии в получаемое случайное число, но выравнивает распределение случайных величин. Т.е. в сумме это всё равно будет не качественное случайное число. А, главное, есть вероятность его повторения, которой по словам ТС быть не должно в принципе.

Если ТС нужен GUID/UUID, то как раз наоборот хорошо. Согласен, но про ключи у ТС речи не шло. В любом случае решать ТС, т.к. мы не знаем сути прикладной задачи, которую он пытается решить с помощью этого механизма.

Есть два варианта: ноль и всё остальное. 😉 В данном случае будет не ноль, хотя и очень малое число, но не ноль.

Ваш, @jcxz, вариант на АЦП, к сожалению, не отвечает этому требованию. Вообще у ТС задача очень похожа на задачу получения GUID/UUID и по-моему поэтому не стоит мудрить. Это пока, к сожалению, только умозрительная оценка. Я, например, наблюдал на выходе аппаратного генератора случайных чисел МК от Миландра К1986ВК025 далеко не случайные последовательности типа 0xDEADBEEF и т.п. Сильно удивлялись вместе с коллегами и смеялись, а потом оказалось, что количество энтропии там мало, поэтому получались всякие смешные комбинации. Если энтропию копить и правильно обрабатывать (размешивать и т.п.), то результат получается сильно лучше. В предлагаемом вами варианте нет никаких гарантий отсутствия повторений, т.к. если основным источником шума в АЦП будет помеха от работы какого-либо узла платы или от самого МК, то увы, повторения будут, вопрос размера выборки. Да, и именно это обеспечивает гарантию отсутствия повторений за заданное время.

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

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

Не у всех STM32 он есть аппаратный. Пока ТС не уточнит, какие именно STM32 он рассматривает, то что-то определённое предложить сложно.

Главное не забывайте, что с точки зрения логики энумерации PCIe это тот же PCI с дополнениями. Поэтому можно смело начинать читать, как это делалось/делается для PCI.

Всё это описано в стандарте, но в разных его частях. Поэтому могу предложить вам почитать книгу, которая есть на местном FTP в /pub/DOC/STANDARDS/PCI/Whitepapers/Budruk R., Anderson D., Shanley T., PCI Express System Architecture(2003).pdf Начните с главы 21. Такой опыт есть, правда не на Zynq, а на Artix. Но в целом разницы нет, и там, и там Root Complex. Вы управляете ресетом, даёте ресет, IP поднимает линк, далее вы сами должны сформировать конфигурационные транзакции для поиска устройств (endpoint) на шине, записывает параметры в их регистры (назначает адреса, разрешает работу MEM/IO) и выполняет транзакции чтения/записи. В целом там нет ничего сложного, звучит это страшнее, чем есть на самом деле.

Опишите вашу задачу, что именно и для чего должен делать ваш хост. В общем случае порядок действий такой: ресет, подъём линка, энумерация, назначение базовых адресов, разрешение работы (настройка управляющих регистров в пространстве конфигурации), обмен данными (чтение/запись по адресам BAR и/или обмен в режиме DMA).

https://github.com/tdrozdovskiy/i2c_eeprom_blk - не пробовали?